bun test: rank "no timeout" as the latest deadline for spawnSync in a concurrent group - #46213

Repro (bun test ./sib.test.ts)

import { test } from "bun:test";
const ignore = { stdin: "ignore", stdout: "ignore", stderr: "ignore" } as const;
test.concurrent("times out", async () => {
  await new Promise(() => {});
}, 100);
test.concurrent("has no timeout", async () => {
  await new Promise(resolve => setImmediate(resolve));
  const start = performance.now();
  const r = Bun.spawnSync({ cmd: ["sleep", "1"], ...ignore });
  console.log("child:", r.exitCode, r.signalCode ?? null, "after", Math.round(performance.now() - start), "ms");
}, 0);

There is no issue for this. It turned up while reading the wait loop for #45792.

Where the rule comes from

get_active_timeout() has one caller, the wait loop in spawn_maybe_sync (src/runtime/api/bun/js_bun_spawn_bindings.rs:1844). child_process.spawnSync, execFileSync and execSync reach it through Bun.spawnSync.

Two comments on main say what the runner must not do:

• Execution.rs:311, on the kill of dangling processes: "when using test.concurrent(), we can't do this because it could kill multiple tests at once."
• js_bun_spawn_bindings.rs:1895: "There is a scenario where inside of spawnSync() a totally different test fails, and that SHOULD be okay."

#33832 made the loop signal the child at the runner's deadline. Its last commit took the latest deadline of the group "so a sibling never terminates early". The comparison it used treats EPOCH as the earliest time. An entry with no timeout has EPOCH (Execution::on_entry_started), so it never won.

docs/test/runtime-behavior.mdx gives 0 and Infinity as one setting. Infinity is stored as a deadline 49 days away (ScopeFunctions.rs:708), so it did win. With Infinity in the repro, main prints child: 0 null after 1173 ms. This change makes 0 behave as Infinity does.

What each group gives (release builds, child sleep 1 unless noted)

The last two rows are the on_stack_entry arm. This change does not touch them. See "Not changed".

Row 4 is from 1.4.3-canary (367d939, the same runner code) and from the debug build of this branch.

On main, a timed caller after an await is ended at its own deadline only when every other running test has timeout 0. Beside Infinity or a later timeout it waits, as rows 3 and 4 show. A child that never exits then blocks the run until the later deadline, or for good beside Infinity. After this change 0 is in that group too.

Measurements (release builds of main 91e7e3b and of this change on it, same toolchain, Linux x64. Main has since added a main-thread check before the call. The function is the same.)

• kill(2) to the child, main to this branch (gdb catch syscall kill): the repro 1 to 0. The timed caller beside a test with no timeout 1 to 0. Every other row of the table 1 to 1.
• get_active_timeout is inlined into spawn_maybe_sync in both builds. Instructions per turn of the wait loop (gdb stepi from the load of the active file to the point where the deadline is ready, 5 to 100 calls per case, all equal):
  • caller before its first await: 9 to 9, in a serial test and with 5 or 20 running tests.
  • after an await: 46 to 46 in a serial test, 71 to 82 with 2 running tests, 146 to 190 with 5, 521 to 730 with 20, 771 to 785 with 20 running and 10 not started.
• Calls per 100 piped Bun.spawnSync: outside bun test 0 to 0, inside bun test 101 to 100 (one per turn of the wait loop).
• spawn_maybe_sync 24,521 to 24,601 bytes (nm -S). Text 107,072,443 to 107,072,699 bytes (size). Data, bss and the size of the stripped file do not change.
• No allocation, queue entry or syscall is added.

Tests

The 9 cases are one block at the end of test/js/bun/spawn/spawnSync.test.ts. Each runs an inner bun test on a generated file. The child is a script run with the bun under test, so Windows runs the cases too. The one case that needs sh is POSIX only.

• Main fails 6.
  • The four entry points: the test with no timeout asserts that its child exited with 0.
  • A sibling that times out once and passes on its retry: the inner run exits 1 on main and 0 here. The signal alone made that run fail.
  • A piped child whose grandchild writes after the deadline: main returns "early\n" with exit code 0, this branch "early\nlate\n".
• Main passes 3. They pin what must not change.
  • The latest timeout still ends the child when every running test has one.
  • A test that has not started does not count as "no timeout" (--max-concurrency 1).
  • A caller before its first await is still ended at its own timeout, also beside a test with no timeout.
• Each clause is needed. With plain order the 6 cases fail. Without the executing filter the --max-concurrency 1 case fails. I checked both with a local build.
• The block runs one case at a time on debug and ASAN builds. Five at once took up to 3.7 s per case on a debug build, against the 5 s limit.

Runs on the debug (ASAN) build:

• test/js/bun/spawn/spawnSync.test.ts: 26 pass, 4 skip. The new block: 9 of 9 in 6 runs.
• test/cli/test/test-timeout-behavior.test.ts, test/js/bun/test/concurrent_immediate.test.ts, bun_test.test.ts, failure-skip.test.ts, jest-hooks.test.ts, test-retry-repeats-basic.test.ts, test/js/node/test_runner/node-test.test.ts, test/js/bun/spawn/spawnsync-no-microtask-drain.test.ts, test/regression/issue/23865.test.ts: all pass.
• test/js/bun/test/concurrent.test.ts runs into its 5 s limits on the debug build of main and of this branch alike. 0 to 6 of its 6 cases fail per run. It does not call spawnSync.
• Not run: Windows and macOS.

The first shape of this change, and why it is gone

I first removed the on_stack_entry arm too, so that one rule covered every caller. A self-review rejected that shape. I checked its reasons:

• bun test: Vitest compatibility #44833 keeps the arm and repairs the cell where it is set. Its doc comment says: "Cleared before the call's microtasks drain, because those can resume other tests in the group".
• Without the arm, a hung child of a 100 ms caller blocks the thread until the latest deadline of the group. With siblings of 400 ms and 800 ms, main gives 2 pass and 1 fail. The build without the arm gave 0 pass and 3 fail.
• bun test: on a timeout, kill only the processes the timed-out test or hook callback spawned #45081 and bun test: a matcher blocked on a promise that never settles fails with the test timeout #39089 read the cell.

This diff merges into #44833 (8130ea5), #45081, #39657, #39440 and #44613 with no conflict. It has one conflict with #45792: the harness import line of spawnSync.test.ts.

Self-review: the concerns

Addressed:

1. The body said that a timed caller is still reported as timed out. It now says (pass) for the one shape where that holds.
2. A hung child failed every sibling. The arm is back, so this is as on main.
3. The pipes of a child that has exited are closed with the signal. A case now pins the output.
4. The cases did not pin the arm. One case now does.
5. The regex for the verdict lines needed a duration. A test that takes no time has none. The duration is now optional.
6. The cases failed on a printed line only. The test with no timeout now asserts, and one case has a different exit code on main.
7. The entry-frame check that can prove a synchronous caller is named under "Not changed".
8. Measurement hygiene: every number here comes from a binary built from the named commit.

Not taken:

• Store timeout 0 as a far deadline, as Infinity is. Then the fold is right as written. It arms the file timer for every test with no timeout. Every spawnSync wait in such a test then gets a deadline to wake for. A typed deadline on ExecutionEntry is the larger form of the same idea.
• The file-timer value that the function returns outside the execution phase can be a stale deadline. It is the same on main.
• A docs sentence for concurrent groups. docs/test/writing-tests.mdx:120 is the paragraph that bun test: SIGKILL a spawnSync child that is still running 500 ms after the test's timeout #45792 edits, and no doc describes the old behavior.

Review of the first push

• The block now also runs one case at a time on ASAN builds.
• "The 6 cases can pass on the unfixed build when the turn of the event loop takes more than 100 ms." They cannot. auto_tick (src/runtime/jsc_hooks.rs) runs the immediates before it polls and before it drains the timers, so the sibling is still running when the test with no timeout calls spawnSync. The wait loop then finds a deadline in the past and signals at once. With a 250 ms Bun.sleepSync before the await, 1.4.3-canary still prints spawned 251 ms after the sibling started: child exitCode null, signalCode SIGTERM, 3 of 3 runs.
• "A child that never exits now blocks the run." That is the first Downside, and it now says so. The two rules proposed for it do not help. The latest deadline that is not EPOCH is what main computes: it is this defect. A far deadline for 0 is what Infinity has: the wait then lasts 49 days.

Not changed

• The on_stack_entry arm names the callback that the runner entered. A test that resumes in the microtask drain of that callback gets its deadline. So does a test that resumes while it waits in expect().resolves. These are the last two rows of the table. bun test: Vitest compatibility #44833 clears the cell before the drain and has no blocking matcher wait. A test that calls drainMicrotasks() itself still resumes a sibling under the cell on main. A check of the VM entry frame together with that clear would close that form.
• Execution::kill_dangling_processes_on_timeout (Execution.rs:322) compares a deadline that can be EPOCH with the plain order. fix(test): preserve unlimited test children after stale deadlines #44613 and bun test: on a timeout, kill only the processes the timed-out test or hook callback spawned #45081 change that line.
• A test that overruns its timeout inside spawnSync and then completes reads (pass). Main does that beside a sibling with a later timeout. bun test: time out a test or hook whose callback completes after its deadline #39440 reports such a test as timed out, and bun test: setDefaultTimeout() in a preload applies only to the first file, and a sync block after a timer escapes the timeout #45192 is a user report of that verdict. This change should land with or after bun test: time out a test or hook whose callback completes after its deadline #39440.
• bun test: SIGKILL a spawnSync child that is still running 500 ms after the test's timeout #45792's case for concurrent groups uses killSignal: "SIGURG". With this change its child gets no signal, so the case no longer reaches the force_kill_at guard. A group where every test has a timeout still does.